home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 15476 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB

  1. Path: ix.netcom.com!netnews
  2. From: miker3@ix.netcom.com (Mike Rubenstein)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: COLLEGE PROFESSORS! # 2/2
  5. Date: Fri, 19 Apr 1996 00:29:28 GMT
  6. Organization: Netcom
  7. Message-ID: <3176db6c.93040194@nntp.ix.netcom.com>
  8. References: <8BEC555.02C70031C4.uuout@sourcebbs.com>
  9. NNTP-Posting-Host: ix-dc6-10.ix.netcom.com
  10. X-NETCOM-Date: Thu Apr 18  5:29:33 PM PDT 1996
  11. X-Newsreader: Forte Agent .99d/32.182
  12.  
  13. david.mohorn@sourcebbs.com (DAVID MOHORN) wrote:
  14.  
  15. > (Continued from previous message)
  16. > return StatusSwitch
  17. > *** end of validation routine ***
  18. > Clearly, example 1 is inefficient and wastes processing time by
  19. > continuing to check for valid data once an error is found and wasting
  20. > another few CPU cycles making another comparison.
  21. > Example 2 to me seems like the best approach by returning to the caller
  22. > immediately once and error if found.
  23. > Example 3 is almost as good as 2, since the nested-ifs will not continue
  24. > to validate data once an error is found.
  25. > The instructors philosophy is to make it more "readable" and keep it as
  26. > structured as possible!  As if structured programming was the only way
  27. > to accomplish this task.  He also stated that nested ifs make the code
  28. > harder to read. He also stated that there is no arm in wasting a
  29. > few milliseconds doing the extra conditions, since it won't be
  30. > noticeable anyway.
  31. > I retorted his remark and said it would on a multitasking system where
  32. > every cycle counts!  If I were validating 10,000 data items, example 1
  33. > would take a considerable amount of time longer than example 2!
  34. > Does anyone else have any opinions or horror stories?
  35.  
  36. You should have a little more sympathy for your professor.  Obviously,
  37. your poor instructor's mind has been destroyed from years of trying to
  38. teach students who are too stupid to post to appropriate newsgroups.
  39.  
  40. In fact, what your instructor says is correct.  A few microseconds (if
  41. you actually have a machine so slow that his method is wasting
  42. milliseconds you've got much bigger problems) don't make a difference
  43. in most programs.  Clarity of code should be the main objective in
  44. initial coding; later, if the program is too slow you can profile it
  45. and find out where to optimize.  Usually the clear code will be fast
  46. enough.  Where it isn't, you'll usually find that you can make it fast
  47. enough by optimizing a rather small number of lines of code.
  48.  
  49. It's easier to make good code fast than to make fast code good.
  50.  
  51. While I don't always, or even usually, code in your instructor's
  52. style, most of my larger programs will have a few functions that are
  53. coded that way for clarity and ease of maintenance.
  54.  
  55.  
  56. Michael M Rubenstein
  57.